General guidelines for updating SSWEs and PWEs

The updating procedure for both SSWEs and PWEs is very similar. When updating both types of working environments, we strongly suggest that you follow these general guidelines: (The updating instructions later on in the chapter are based on these guidelines.)

- Whenever you update a working environment, also update any other working environment that accesses it. First update the topmost working environment (the one that doesn't access any other one and is accessed by all others) and work "downwards". For example, suppose your team uses one SSWE, one SOWE and several PWEs. You would first update the SSWE (both SOWE and PWEs access it), then the SOWE (the PWEs access it) and finally the PWEs.
- When updating a working environment, compare all local, read-only files in it, or in any accessed working environment, to the latest version in the Repository. If the latest version in the Repository is newer, check it out in the working environment being updated.
- When updating a Private Working Environment, remove all read-only files in it. Do nothing to local, writable files (checked-out usually).

Rollback in case of unsuccessful builds in the SOWE
Builds in a SOWE are not always successful, especially if one of your team members has checked in files without first testing them locally. To avoid such a situation, we recommend that you implement a rollback mechanism that restores your SSWEs and SOWE to their status before the update. The only implication for the team in such a case is that they will continue to work with the same version as they did before the unsuccessful update. Your Working Environments Administrator can then investigate the problem and fix it without disrupting your team's development work. Of course, implementing a rollback mechanism in your updating procedure means that you will have to make a backup of your SSWEs and SOWE before starting the update.
Model for updating shared working environments
Here's how an updating and build process with a rollback mechanism might look like for your team's shared working environments:

Workspace projects
To make it easier to update working environments, we recommend that you set up a workspace project as a root project of all other projects in a working environment. Workspace projects have two main advantages:

- To update all the projects in a working environment, you just have to update the workspace project, since SNiFF+ automatically updates all its subprojects for you.
- Unattended automatic nightly updates and builds are easier if there is a single workspace project for a working environment.

You should create workspace projects before you begin updating working environments for the first time. To create a workspace project for a working environment that already contains SNiFF+ projects:

Open the Working Environments tool and select the working environment for which you want to create the workspace project.
Choose File > New Project... > with Defaults....
Select the root directory of the working environment as the project directory.
A Project Attributes dialog for a new project is opened.
Select the General node.
Give the project a name that clearly describes it (e.g.,

workspace.shared ).
Clear the Generate Subproject Tree check box, since you do not want to create SNiFF+ projects for the entire project tree again.
Press the Ok button to create the workspace project.
SNiFF+ will now generate the workspace project and its associated files. A Progress dialog appears to inform you of the generation process. When the generation process is over, SNiFF+ automatically opens the new project and displays its structure in a Project Editor.
Manually add all root projects of the working environment as subprojects by choosing Project > Add subproject... in the Project Editor for each project you want to add.